1. Field of the Invention
This invention generally relates to distributed multi-channel computer systems, and more specifically, to efficient selection of a messaging multiplexed channel instances in such systems.
2. Background Art
Distributed computing systems are in common use today, as they offer many important advantages, including large capacity, quick response, distributed workloads, high reliability and extensive resources and functionalities. In these systems, a number of client applications, running on one or more client computers or stations, communicate with a number of server applications, running on one or more server computers.
A number of communications channel instances are provided for handling the communications between the client and server applications; and when a client application requests access to a server application, one of those channel instances is selected to handle the communications traffic between the two applications. With current technology, a single channel instance can handle communications in both directions between a client and a server, and, in fact, one channel instance can handle communications in both directions between multiple client applications and a server. This technology increases very substantially the amount of communications that can be handled by a given number of channel instances. When single channel instances handle communications between plural client applications and a server, selecting the appropriate channel instance for the communications between a client application and a server may be difficult because different communication streams require different protocols. A specific protocol is established for a given channel instance; only communications that can be handled using that protocol can be added to that channel instance.
Application connections from a messaging client may be multiplexed over a single communications channel instance, such as a TCP/IP socket. The first application connection on a particular channel instance causes the protocol set-up (e.g. socket) flows to occur, which are followed by other flows which determine the nature of the connectivity on that messaging channel instance/socket. For instance, the value of a messaging heartbeat interval may be negotiated at this stage (the heartbeat being sent on an idle channel instance to check for connectivity problems). Another example of these subsequent flows may involve an SSL handshake, which allows for mutual authentication of the parties at both ends of the channel instance, and sets up algorithms for subsequent data encryption and data hashing.
Subsequent application connections can only multiplex onto a particular channel instance if the channel characteristics, such as SSL connectivity, specified for the application connection match those associated with that channel instance. They can also only multiplex onto a channel instance if that channel instance supports multiplexing and has not reached its multiplexing limit. So, once the first connection on the channel instance has completed its connection flows, a new matching application connection will multiplex with it provided that the channel instance is configured to support multiplexing after its initial flows are complete.
The problem with this scenario is that while channel instances are first connecting, there can be a significant delay, for instance SSL negotiation is very processing-intensive, slow lines may be involved to transmit the negotiation flows, overloaded systems may not respond promptly, connection attempts to invalid destinations can be particularly lengthy. If an attempt is made to make a new application connection with characteristics which match a channel instance connection that is still in the process of connecting, it is impossible to tell immediately whether this new application connection can be multiplexed on this channel instance or not.
One very simple solution to this problem is to disregard connecting channels when looking for a matching channel instance. With this approach, when a number of identical SSL connections from a particular client are all started at almost the same time, the first connection would get into the connecting state on a particular channel instance. The second connection would not attempt to multiplex onto that channel instance, as it was still connecting, and would connect on a new channel instance. And so would the third connection, etc. So, the end result is many different channel instances connected, when with appropriate waiting, all of the application connections could have used the same one channel instance. If these application connection attempts were instead made to wait for the initial channel instance set-up to complete, multiplexing would be maximized and hence resource usage minimized.
One simple way to enforce such a wait is to lock access to all the existing channel connection information while a new channel instance is connecting. The lock is freed once the channel instance set up flows have completed; at this stage, all channel instances will be in a connected state and a matching one with room to multiplex can be securely found.
This solution ensures that opportunities for multiplexing are fully utilized; it is also reliable and simple. It does, however, have clear drawbacks with regard to performance. A channel instance may be in the process of connecting but be subject to severe connection delays. During this period, many application requests may be made to connect with completely different channel instance characteristics to those specified on the delayed channel instance. These application connections could succeed independently of the delayed channel instance connection, as they would occur on a different channel instance/socket, but are prevented from doing so because of the lock set by the delayed channel instance.